IBIS Macromodel Task Group

Meeting date: 11 June 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:                Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Dassault Systemes:            Longfei Bai                             
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Chi-te Chen
                            * Liwei Zhao
                              Alaeddin Aydiner
                            * Sai Zhou
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):           Walter Katz
                              Graham Kus
Micron Technology:          * Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                              Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
                              Randy Wolff
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Sai Zhou introduced himself to the group.  He works on developing internal EDA
  tools at Intel.  He joined the meeting to discuss some questions about PAM4
  parameters.
  
- Michael said he would propose tabling the [Clock Pins] update.
  
-------------
Review of ARs:

None.
            
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the May 21st
meeting.  Michael moved to approve the minutes.  Ambrish seconded the motion.
There were no objections.

--------------
New Discussion:

Fixing [Clock Pins]:
Michael moved to table this topic.  He said he had more pressing near term
questions for ATM including Usage In vs. Info and the use of [Ramp] and Ts4file.
Curtis seconded the motion.  There were no objections.  Arpad moved this item to
the tabled topics.

PAM4_Mapping Usage questions:
Sai said that PAM4_Mapping allowing both Usage In and Info could cause
confusion.  He asked whether we had to worry about the tool and the model each
thinking they had to deal with mapping.  Fangyi said the definition states:
  "Tells the EDA tool how to map voltage levels to two-bit PAM4 symbols"
Fangyi said the PAM4_Mapping information is used by the tool.  Fangyi noted that
the input to a PAM4 Tx model is a 4-level waveform that has been generated by
the tool.  It's the tool that has to know how to convert the two-bit PAM4 symbol
to a voltage level.

Michael asked why we allow Usage In for this parameter at all.  Fangyi said that
typically it would be Usage Info, but you might have a model that wanted to
handle some non-linearity or noise modeling differently according to the
PAM4_Mapping.  In that case, the parameter (in the .ami file) provides a list of
the possible values, the user selects one, and it is passed into the model.
However, the model should not be using the PAM4_Mapping parameter's value to
redo the mapping.  The mapping is handled by the tool.

Arpad noted that newer, more general, PAMn parameters had superseded the older
PAM4 parameters.  He asked whether our intent had been to deprecate the older
PAM4 parameters altogether.  Ambrish noted that Modulation and PAM4_Mapping are
the only Reserved parameters that allow both Usage In and Usage Info.
Modulation_Levels, the new PAMn parameter analogous to Modulation, only allows
Usage In.  It is clear that the tool needs to know the value of Modulation, even
though it's Usage In.  Ambrish also noted that with the new PAMn parameters we
intentionally left mapping up to the EDA tool.  There is no Reserved Parameter
analogous to the older PAM4_Mapping.

Liwei and Sai explained that in their internal AMI model they use the
PAM4_Mapping information to map voltage levels back to binary so they can do
internal BER calculations.  Fangyi said this is fine, but it's internal to the
to the model.

Ambrish noted that on page 281, of IBIS 7.2, it is "highly recommended" that
model makers use the newer PAMn parameters.  Michael said that model makers are
sometimes constrained by the particular model development tool they're using.
Unless they're writing models from scratch they have to live within the confines
of the tools they're using to develop AMI models.  Fangyi and Curtis noted that
the model Liwei and Sai were describing wouldn't work with the PAMn Reserved
Parameters, as there is no mapping parameter.

Arpad asked whether we should add clarifying language stating that Usage In
parameters are for the model, but for Reserved Parameters the EDA tool is also
able to use the information.  Ambrish suggested that we not open a can of worms,
since the PAM4 parameters have been superseded anyway.  Michael said we might
want a few clarification statements, for example, Model Specific parameters are
not expected to be Usage Info (since EDA tools aren't supposed to know what
Model Specific parameters mean).  Arpad said he had originally proposed such a
restriction, but others had argued that it would stifle innovation if people
couldn't distribute developmental models with special features.  He noted that
the result of those discussions was BIRD179, which had introduced a new
Special_Param_Names parameter model makers should use to enumerate any Model
Specific parameters that require special handling by an EDA tool (introduced in
IBIS 7.0).

MIPI C-phy support in IBIS:
Arpad shared a work-in-progress "C-phy Overview for IBIS" to help spur
discussion about whether IBIS should introduce changes to support C-phy.  He
reviewed a high-level diagram including 16 bit to 7 symbol mapping, parallel to
serial conversion, symbol encoding for the 3-wire driver, and the elaborate
state machine that controls the allowable transitions.  Arpad noted that IBIS
probably doesn't have to involve itself with most of this, and IBIS could focus
on characterizing the analog buffer behaviors for the Tx and Rx triplets.

He then focused on the analog buffer portion.  He reviewed a diagram of an
equivalent circuit for the 3-wire Tx.  The buffers have a 50 Ohm impedance
when driving high or low, and when driving the mid-state they have 100 Ohm
impedances to high and low and effectively maintain a 50 Ohm impedance.  Arpad
said we could model this equivalent system in IBIS if we had 100 Ohm models
in the [Model] and [Submodel] keywords.  If they were driven in the same
direction we would have a 50 Ohm pullup or pulldown, and if driven in the
opposite directions we could duplicate the mid-state behavior.  Arpad noted
that there might be issues with the accuracy of the edge rates with this
approach, depending on whether the two models drive in the same or opposite
directions.  This may involve issues with the way the C_comp compensation
algorithm is implemented for the K(t) coefficient computations.  Arpad said we
might need new keywords or subparameters to define independent stimuli for the
[Model] and [Submodel], but this would be a relatively simple change.

Arpad discussed C-phy equalization.  For the Tx, equalization is implemented by
having 3 sublevels for each of the 3 output levels (e.g., for the high level,
there are H2, H1, H0 sublevels), and only allowing certain transitions (e.g.,
when transitioning from high to low, for example, the transition occurs from any
of the 3 high sublevels to only L2).  Arpad said the Tx equalization is defined
in terms of impedances for main and sub buffers, and it's difficult or
impossible to associate a single equalization dB for all transitions.  The
equalization is defined in terms of Main and Sub buffer impedances, and Arpad
reviewed a diagram of an equivalent circuit.  Arpad noted that the Main and Sub
buffers in this context are not the same as IBIS' [Model] and [Submodel].  Arpad
said he was describing this so we can think about whether or how we would
support this in regular I/V based IBIS or AMI.

Arpad said that handling this Tx equalization with [Submodel]s would become more
complicated, as we would have to add support for multiple [Submodel]s.  He said
we might be better off defining a more "native" IBIS approach and adding
multiple sets of I/V and V/t tables to describe the buffers' impedance at each
level and the transitions between the various levels.  It might be better to
introduce a new keyword for this instead of overloading the existing [Model]
keyword.  Yet another option would be to let model makers implement this in
[External Model] using Verilog-A or VHDL-AMS.

Arpad said the C-phy Rx has an optional 2-pole, 1-zero CTLE, and there is no
DFE.  He noted that his discussion is based on the 2019 version of the standard,
and wondered if more equalization would be added in the future.

The meeting ended before discussion of the overview was complete.  Discussion
will continue next week. 

- Michael: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

None.

-------------
Next meeting: 18 June 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
